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Refadoring can improve the quality of a software system as measured by coupling, cohesion, and tyclomatic complexity, hut 
knowing which refactoring choices should be implemented is bey. This article presents an approach that guides the refactoring 
of software systems by combining the use of software metrics and a technique called program slicing. Program slices produced 
from a single software module are sorted by the respective values of the metrics; a design that provides the most beneficial met¬ 
ric values can be selected from these. This approach can produce a software system with higher quality and maintainability as 
measured by the metrics. 


M any systems designed today have 
very long life cycles, especially in 
the military. Often, a software program 
is expected to perform for many years, 
and undergo frequent updates and 
requirements changes. Large-scale soft¬ 
ware systems are prone to quality prob¬ 
lems [1] during development. Constant 
changes to existing systems only lead to 
additional quality problems. 

One way to help control defects and 
reduce high maintenance costs is to use 
refactoring. Refactoring is the process of 
changing a software system in such a way 
that it does not alter the external behav¬ 
ior of the code yet improves its internal 
structure [2]. Refactoring is an option 
during both the development and main¬ 
tenance phases. Unfortunately, refactor¬ 
ing the design can be very resource 
intensive, and automated tool support is 
considered crucial [3], 

This article presents an approach for 
automating a large part of the evaluation 
and refactoring process. By combining 
the use of software metrics and a tech¬ 
nique called program slicing, the refac¬ 
toring process is guided toward a design 
with higher quality and more maintain¬ 
ability. First, we discuss how several dif¬ 
ferent software metrics can be used to 
evaluate software quality and the effects 
those metrics have on defects, testing 
effort, and maintenance cost. We then 
discuss how program slicing can use 
those metrics to guide design-refactoring 
decisions. The final section presents our 
conclusions. 

Software Metrics 

We use software metrics to try to quanti¬ 
fy particular characteristics of software 
systems, such as quality, maintainability, 
or reliability. In general, however, these 
characteristics cannot be measured 
directly. Instead, we directly measure 
particular attributes of software by using 


software metrics and then infer informa¬ 
tion about quality from those direct 
measurements [4]. 

Three commonly used software met¬ 
rics are coupling, cohesion, and 
McCabe’s Cyclomatic Complexity [5]; all 
three have been extended from their 
original definitions for use with object- 

“One way to help 
control defects and 
reduce high 
maintenance costs is 
to use refactoring.” 

oriented systems (OOS). In this article, 
we discuss our ideas in the context of a 
system that was implemented using 
structured design techniques, though the 
process could also be extended for use 
with OOS. 

The first metric to consider is cou¬ 
pling, which measures the strength of 
the connections between the software 
modules that comprise a particular sys¬ 
tem to quantify the dependencies 
between the modules. The key idea is 
that the more interdependent the mod¬ 
ules in the system are, the more difficult 
the system is to understand and the more 
likely it is that changes to one module 
will affect other modules in the system. 

Yourdon [6] originally described sev¬ 
eral different kinds of coupling, includ¬ 
ing data coupling, control coupling, 
hybrid coupling, and so on. McConnell 
[7] has updated coupling to include class¬ 
es of coupling. In the technique 
described in the following section, we 
only consider data — or normal — cou¬ 
pling. In other words, the main focus in 
terms of coupling is on the information 


that flows between the modules in the 
system. We measure this coupling by 
counting the number of parameters (i.e., 
pieces of information) passed into and 
out of each module. 

As Yourdon points out, “The cou¬ 
pling between modules in tentative 
structural designs can be evaluated to 
guide the designer toward less expensive 
structures.” Our idea is to provide pre¬ 
cisely this kind of guidance, but to do so 
with extensive automated tool support. 
This guidance would be useful in both 
the design and the maintenance phases, 
though we believe most refactoring 
occurs in the maintenance phase. 

The second metric to consider is 
cohesion, which measures how strongly 
the elements of each module are related 
to each other. Cohesion was originally 
defined in an article by Stevens [8], and 
the concept has been updated as pro¬ 
gramming languages and their capabili¬ 
ties have evolved. McConnell [7] con¬ 
tains a working definition of the current 
classes of cohesion. At a high level, a 
module with high cohesion accomplish¬ 
es a single function using only the data 
required to accomplish that function. As 
with coupling, Yourdon defined multiple 
levels of cohesion, though we limit our 
interest to functional cohesion in this 
article. 

Coupling and cohesion are related, 
though not perfectly correlated. As we 
increase the cohesion of the modules in 
the system, we tend to reduce the cou¬ 
pling between those modules. This is an 
important consideration, because al¬ 
though researchers have proposed vari¬ 
ous ways to measure cohesion [9], it is 
much more difficult to measure than 
coupling. In this approach we do not 
measure cohesion directly, but instead 
rely on the relationship between cou¬ 
pling and cohesion to infer information 
about the quality of a module. If we find 
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that we also need to direcdy measure 
cohesion to make our approach more 
effective in practice, we can extend the 
metrics calculated by the tool to include 
cohesion as well. 

The final metric, which is probably 
the most commonly used metric of 
those discussed here, is McCabe’s 
Cyclomatic Complexity. At the module 
level, this metric is the number of linear¬ 
ly independent paths through the mod¬ 
ule. Modules that contain many possible 
paths are more complex than those with 
fewer paths, so as the cyclomatic com¬ 
plexity of a module increases, so does its 
complexity. We note that this metric is 
equal to one more than the number of 
decisions contained in the module. 

Based on the discussion above, our 
approach uses coupling and cyclomatic 
complexity metrics as described in the 
following section. The coupling metric 
provides insight into the interaction 
between the modules in the system, 
while the cyclomatic complexity metric 
gives insight into the complexity of each 
individual module. Remember that we do 
not direcdy include cohesion, though we 
could extend our approach to do so if it 
proves to be helpful in practice. 

As stated in the introduction, our 
goal is to use software metrics to provide 
guidance to those undertaking refactor¬ 
ing efforts. It is important to note, of 
course, that we do not refactor code sim¬ 
ply for the sake of better code; rather, we 
expect some return on the investment 
expended on any refactoring efforts. We 
must therefore consider some of the 
important relationships between our 
software metrics and software quality, 
testing costs, and maintenance costs. 

Intuitively, we expect software with 
high coupling and low cohesion to be of 
lower quality than software with low 
coupling and high cohesion. The addi¬ 
tional programmer effort required for 
understanding highly interrelated mod¬ 
ules and their effects on each other leads 
to a higher potential for mistakes. 
Similarly, a programmer working on a 
module with low cohesion needs to keep 
track of multiple functions being per¬ 
formed by the module rather than on a 
single function, which also increases the 
potential for programmer error. Our 
intuition turns out to be true in practice. 
Research on operational systems has 
shown that modules with high cou¬ 
pling/low cohesion contained seven 
times as many errors as modules with 
low coupling/high cohesion [10]. In 
addition, programmers spent almost 22 
times as many hours correcting the 


errors in those modules with high cou¬ 
pling/low cohesion. Clearly, coupling 
and cohesion have a significant impact 
on both the quality of the software and 
the effort required to fix errors in the 
software. 

We also expect all three metrics to 
have an impact on the amount of effort 
associated with software testing. Because 
coupling measures the dependencies 
between modules, higher coupling 
implies the need to expend more effort 
accomplishing integration testing of the 
modules. Modules with low cohesion 
implement more than one function; test¬ 
ing the functionality of that module (typ¬ 
ically during unit testing) requires more 
test cases to cover all of that module’s 
functionality. Cyclomatic complexity 
essentially measures the number of 
paths through a module, so modules 
with higher cyclomatic complexity will 
require more test cases to cover all the 
paths. 

“The coupling metric 
provides insight into the 
interaction between the 
modules in the system, 
while the cyclomatic 
complexity metric gives 
insight into the 
complexity of each 
individual module.” 

Discussions of software quality and 
testing effort apply both to the original 
development of a system and mainte¬ 
nance of that system. We are also con¬ 
cerned, of course, with the cost of main¬ 
taining systems. Research shows that we 
can account for more than half of the 
variability of maintenance productivity 
by taking cyclomatic complexity into 
account [11]; in other words, we can sig¬ 
nificantly improve our estimates of 
maintenance costs through considera¬ 
tion of the cyclomatic complexity (and 
lines of code) for the system to be main¬ 
tained. Perhaps even more importantly, 
we know that modules with higher cyclo¬ 
matic complexity are more difficult to 
maintain, so if we can reduce the com¬ 
plexity of the modules we can reason¬ 
ably expect a corresponding reduction in 


maintenance costs. 

It is clear that refactoring software to 
improve coupling, cohesion, and cyclo¬ 
matic complexity of the software yields 
improvements in overall software quality 
and reductions in testing and mainte¬ 
nance costs. Despite the clear benefits 
associated with refactoring, the amount 
of effort required to refactor large sys¬ 
tems without tool support is generally 
prohibitive [3], Metrics and other meth¬ 
ods have been proposed to help guide 
program refactoring [12,13,14,15], One 
problem with traditional metrics is that 
they are often not useful for making fine 
distinctions between routines and mod¬ 
ules [7, 16], Refactoring does not have 
this limitation. The following section 
describes our approach for guiding the 
refactoring process through the use of 
program slicing and software metrics. 

Program Slicing, Metrics, and 
Refactoring 

When considering options for refactor¬ 
ing, a technique known as program slic¬ 
ing can be used to isolate portions of a 
software system. A program slice is a 
projection of the behavior from a soft¬ 
ware module that is needed to produce a 
particular value in the module [17], By 
slicing a particular variable or parameter 
in a software module, only the lines of 
code required to produce that variable or 
parameter are extracted from the mod¬ 
ule. The resulting lines of code can be 
built into a separate module with vari¬ 
ables and parameters of their own. 

For example, consider the Ada proce¬ 
dure shown on the left side in Figure 1 
(see page 22). This procedure produces 
both the Highest_Max parameter and 
the Lowest_Min parameter. The Ada 
procedure shown in the upper right side 
of Figure 1 shows the program slice 
built by slicing on the Highest_Max 
parameter. The Ada procedure shown in 
the lower right side of Figure 1 shows 
the program slice built by slicing on the 
Lowest_Min parameter. Note that only 
those parameters needed to produce 
either Highest_Max or Lowest_Min are 
included in their respective program 
slices. 

Program slicing is useful for refactor¬ 
ing software systems [18] because it iso¬ 
lates portions of the software. For exam¬ 
ple as shown in Figure 1, instead of a 
single procedure that produces both the 
Highest_Max value and the Lowes t_Min 
value, we now have two procedures that 
each produce a single value. The chal¬ 
lenge with using program slicing for 
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Figure 1: A Predictable Substation Assembly 


refactoring is determining how to slice 
the software system properly in order to 
maximize maintainability and quality. 

Since we want to refactor our soft¬ 
ware to improve coupling, cohesion, 
and cyclomatic complexity, software 
metrics can guide our choices when we 
use program slicing for refactoring. 
Each time we produce program slices, 
we can compare the values of the met¬ 
rics from the original procedure to the 
resulting program slices. Clearly, pro¬ 
gram slices that produce better cou¬ 
pling, cohesion, and cyclomatic com¬ 
plexity are better than the original pro¬ 
cedure and should be included in the 
refactored software system. 

During refactoring, program slicing 


may reduce the coupling between mod¬ 
ules in the software system. For example, 
in Figure 1 the original procedure 
includes five parameters, but each pro¬ 
gram slice includes only three parame¬ 
ters. As we discussed previously, the 
number of parameters in a software 
module can measure coupling, so in this 
case, program slicing has reduced the 
coupling between modules. 

Program slicing may also improve the 
cyclomatic complexity of a software 
module during refactoring. For the pro¬ 
cedure shown on the left side of Figure 
1, the value of the cyclomatic complexi¬ 
ty metric is three. For each of the pro¬ 
gram slices, the value of that metric is 
two. In this case, refactoring using pro¬ 


Figure 2: Metrics for Program Slices 



gram slices has resulted in software mod¬ 
ules that have a lower value for the cyclo¬ 
matic complexity metric. 

Using program slicing for refactoring 
can therefore improve the quality and 
maintainability of software modules as 
measured by coupling, cohesion, and 
cyclomatic complexity. Admittedly, the 
example shown in Figure 1 is simplistic, 
but it demonstrates how using program 
slicing and metrics can guide the refac¬ 
toring process. 

Slicing on Combinations of 
Variables 

As is often the case, software systems 
contain modules that are much more 
complicated than the one shown in 
Figure 1. Software modules often have 
many different parameters (high cou¬ 
pling) and contain high levels of cyclo¬ 
matic complexity. These modules pres¬ 
ent an opportunity to improve overall 
system quality by refactoring using the 
program slicing technique on different 
combinations of the parameters. 

For example, consider a module that 
produces four values. For illustration, we 
will call the module Produces_Four and 
call the four parameters A, B, C, and D. 
By using program slicing, we can build 
15 different software modules, including 
the original module, from the possible 
combinations of these parameters. We 
can then calculate the coupling and 
cyclomatic complexity metric for each of 
the 15 modules individually. 

Figure 2 shows the values of the cou¬ 
pling and cyclomatic complexity metrics 
for the 15 modules. The reader should 
realize that these are the values for pro¬ 
gram slices that were built from the 
Produces_Four module that we used in 
our example. These values would differ 
for other program slices built from other 
modules depending on the code con¬ 
tained in those modules. Note that in 
Figure 2, the ABCD column represents 
the Produces_Four module. 

The following discussion shows how 
the information in Figure 2 helps to 
guide refactoring decisions. As we can 
see from the figure, slicing the original 
module into four separate modules for 
A, B, C, and D results in the lowest aver¬ 
age coupling and cyclomatic complexity 
for the overall system. The average cou¬ 
pling and complexity of these four sepa¬ 
rate modules is lower than that of the 
original module, so breaking this module 
into four separate modules would be the 
best refactoring choice. The point is to 
lower the overall complexity of the sys- 
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tem. By replacing the Produces_Four 
module, which has high complexity and 
high coupling, with four new modules 
that have lower complexity and lower 
coupling, we can lower the average com¬ 
plexity and coupling for the system. We 
focus on the average of the metrics 
because we want to show that it will be 
easier to maintain the four new modules 
instead of one legacy module. 

It could be the case, however, that 
organizational or management policies 
prevent you from selecting this option. 
For example, limits on the total number 
of modules in the system — or lower lim¬ 
its on the size of those modules — could 
preclude breaking the original module 
into four separate modules in our exam¬ 
ple. Effort should be expended to 
change such policies, especially when 
compliance will result in systems that are 
less maintainable than they could be. We 
also recognize, however, that some 
organizations will impose those policies 
regardless of the resulting impacts. 

In this scenario, which refactoring 
option should you choose? In the fol¬ 
lowing discussion, we assume that our 
policies constrain us to select exactly two 
modules in refactoring the original mod¬ 
ule. 

As shewn in Figure 2, the module for 
values CD has the same coupling and 
complexity as the modules for values 
AB, AC, and AD. All of these modules 
have lower coupling and complexity than 
the modules for BC and for BD. 
Selecting the module for AB along with 
the module for CD is a reasonable 
choice to replace the original module. 
The average coupling for this choice is 4 
and the average complexity for this 
choice is 3. This option results in a lower 
average coupling and complexity for the 
overall system. It is also a better choice 
than selecting the module for AD along 
with the module for BC because the 
module for BC drives up the average 
coupling to 4.5. The values of the met¬ 
rics for these program slices can help the 
software engineer select the best possible 
refactoring option that fits within the 
constraints placed on a software system. 

Further analysis shows that the opti¬ 
mal choice in this situation is to choose 
the module for B along with the module 
for ACD. The average complexity for 
this choice remains at 3, but the average 
coupling is reduced to 3.5. This is a bet¬ 
ter choice than selecting the modules for 
AB and CD, since the average coupling 
and cohesion are less. Clearly, this is the 
best choice if the developer is con¬ 
strained to selecting exactly two modules 
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in the refactoring process. 

This illustrates how refactoring deci¬ 
sions can be guided by using program 
slicing and the values of metrics of the 
resulting program slices. 

Conclusion 

Coupling, cohesion, and cyclomatic 
complexity have become accepted met¬ 
rics for measuring the maintainability 
and quality of software systems. 
Refactoring can improve the quality of a 
system as measured by these metrics, but 
which refactoring choices should be 
implemented? We suggest using pro¬ 
gram slicing in conjunction with soft¬ 
ware metrics to guide the refactoring 
process. By slicing the software system 

“The return on 
investment in this 
refactoring process can 
be measured in lower 
error rates, fewer test 
cases per module, and 
increased overall 
understandability and 
maintainability. ” 


on one or more variables, different refac¬ 
toring options can be examined and eval¬ 
uated using these metrics. The choices 
that program slicing provides can be 
sorted by the respective values of the 
metrics, and a design that provides the 
most beneficial metric values can be 
selected. It is the combination of pro¬ 
gram slicing and software metrics that 
guides the refactoring process. 

A software system that has gone 
through this refactoring process has high¬ 
er quality and is more maintainable. The 
return on investment in this refactoring 
process can be measured in lower error 
rates, fewer test cases per module, and 
increased overall understandability and 
maintainability. In both the design and 
maintenance phase, these advantages can 
be realized almost immediately.^ 
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